Lecciones aprendidas

Historial de versiones

Versión	Fecha	Diferencia entre versiones
1.0	2024-02-22	Versión inicial del documento
2.0	2024-03-01	Actualización del documento
3.0	2024-03-02	Actualización del documento
4.0	2024-05-02	Actualización del documento

1. Resumen ejecutivo

Durante las distintas fases del proyecto han surgido algunos problemas que han sido analizados y resueltos, por ello, en este documento, se ha realizado un registro de las lecciones aprendidas de las que destacan:

• Devising a project: Establecer plazos realistas y equilibrados. Definir criterios claros para evaluar la calidad del trabajo. Contar con planes de contingencia para problemas tecnológicos durante presentaciones importantes. Orientar de forma clara para prevenir malentendidos y garantizar la alineación de las tareas con los objetivos del proyecto

• Sprint 1: Crucial encontrar soluciones alternativas para reducir la dependencia entre el frontend y el backend. La comunicación efectiva y la colaboración entre los equipos son fundamentales para garantizar la coherencia y la alineación en el desarrollo de software.

2. Introducción

Este documento de lecciones aprendidas se centra en analizar las experiencias y los resultados de fases anteriores, identificando las prácticas exitosas, así como los desafíos encontrados y las soluciones aplicadas. A través de este análisis retrospectivo, se pretende proporcionar una guía práctica y perspicaz para futuras fases, destacando las áreas clave donde se pueden aplicar mejoras y ofreciendo una visión valiosa para optimizar la eficiencia y la calidad en proyectos venideros.

3. Devising a project

Esta fase inicial del proyecto ha sido una etapa de adaptación al contexto de la asignatura, de forma que ha supuesto un reto llevar una correcta organización y planificación a lo largo de las semanas. Por ello, han surgido algunos contratiempos de los que se han recogido las siguientes lecciones aprendidas:

• Semana 1:
  • Contexto: Durante la primera semana se hizo un reparto inicial de tareas según equipos, sin embargo, se eligió una deadline muy próxima a la fecha de presentación, esto provocó una carga de trabajo grande para los presentadores en cuestión de un día y se tuvieron que dedicar muchas horas.
    • Lección aprendida: Es fundamental establecer plazos realistas y proporcionar suficiente tiempo para cada fase del trabajo, evitando así acumulaciones de trabajo y situaciones de estrés de última hora. Además, es crucial considerar las capacidades y disponibilidad de los miembros del equipo al asignar tareas y plazos, asegurándose de distribuir la carga de trabajo de manera justa y equilibrada para evitar situaciones de sobrecarga para algunos miembros del equipo.
• Semana 2:
  • Contexto: Con el objetivo de aumentar la calidad de las tareas realizadas, se estableció una estrategia de revisión de las tareas por parte de miembros del equipo. Sin embargo, no había criterios claros establecidos para evaluar la calidad y esto supuso que algunas tareas siguieran teniendo una calidad media/baja.
    • Lección aprendida: Es fundamental establecer criterios claros y objetivos para evaluar la calidad de las tareas. La falta de criterios definidos puede conducir a revisiones inconsistentes y a la aceptación de entregables de calidad inferior. Establecer estándares claros desde el principio garantiza una evaluación coherente y ayuda a mantener un alto nivel de calidad en todas las tareas realizadas por el equipo.
• Semana 3:
  • Contexto Nº1: Se realizó una presentación en Canva conectado al Wi-fi de la universidad, esto provocó que al irse la conexión las imágenes de la presentación no se viesen y por ende la presentación fuera un desastre.
    • Lección aprendida Nº1: La dependencia excesiva de la conectividad a Internet puede resultar en fallos críticos durante presentaciones importantes. Es crucial contar con un plan de contingencia para garantizar la continuidad de las actividades, como tener copias locales de los archivos necesarios o utilizar herramientas que permitan el acceso sin conexión. Además, se debe realizar una verificación previa de los recursos tecnológicos disponibles en el lugar de la presentación para evitar contratiempos debido a limitaciones de infraestructura.
  • Contexto Nº2: Durante esta semana hubo retrasos considerables en las tareas debido a que las personas encargadas de realizarlas no entendieron bien el propósito de la tarea, por lo que provocó que se tuviesen que corregir varias veces y esto provocó una pérdida inmensa de tiempo.
    • Lección aprendida Nº2: La falta de comprensión puede llevar a malentendidos, retrasos y trabajo duplicado. Es importante proporcionar orientación adicional o capacitación si es necesario para asegurar que todos los miembros estén alineados con los objetivos del proyecto.

4. Sprint 1

En esta fase se ha comenzado el desarrollo de los casos de uso principales. Con lo cuál han surgido algunos problemas debido a la organización de tareas y las dependencias entre ellas a lo largo del Sprint.

• Semana 1:
  • Contexto: Al final de ésta semana se ha identificado un cuello de botella procedente de las dependencias entre tareas. Esto fue provocado por el retraso en la implementación de la configuración de testing del repositorio de backend, que hizo que la funcionalidad implementada no pudiese ser testeada y por ello no pudo ser fusionada a develop. El equipo de frontend decidió esperar a que estuvieran las tareas de backend fusionadas para poder continuar provocando esto una etapa de estancamiento.
    • Lección aprendida: La lección aprendida es que es crucial encontrar soluciones alternativas para reducir la dependencia entre el frontend y el backend. Al buscar formas de simular la respuesta del backend, como utilizar herramientas o métodos que imitan su comportamiento, se puede permitir que el desarrollo del frontend continúe de manera independiente. Esto resalta la importancia de mantener la agilidad y la flexibilidad en el proceso de desarrollo para evitar retrasos significativos en el proyecto.
• Semana 2:
  • Contexto: Durante esta semana, se han enfrentado nuevamente a problemas de sincronización entre el frontend y el backend. La falta de comunicación efectiva entre ambos equipos ha llevado a discrepancias en los modelos y mockups utilizados, lo que ha generado retrasos en el desarrollo y dificultades para alcanzar los objetivos establecidos.
    • Lección aprendida: La comunicación efectiva y la colaboración entre los equipos son fundamentales para garantizar la completitud de las tareas en el desarrollo de software. Es esencial establecer canales de comunicación claros y regulares entre los equipos, así como fomentar la transparencia y la participación activa en la toma de decisiones. Además, es importante mantener una comunicación abierta para solucionar cualquier problema o discrepancia de manera eficaz.

5. Sprint 2

En esta fase nos enfocaremos en la mejora del prototipo, implementando funcionalidades como recuperación de contraseña vía email, paginación y buscador interno, entre otros. También continuaremos con la gestión de entrega de alimentos, la unificación de funcionalidades en backend y frontend, y abordaremos posibles imprevistos y errores. Además, nos centraremos en el seguimiento del proyecto y desplegaremos e integraremos en Google Cloud con GitHub Actions.

• Contexto: Debido a la falta de comunicación entre frontend y backend, y a las diferencias en la resolución de problemas, parecía que podían empezar a surgir conflictos internos. Los responsables de la coordinación del grupo hablaron y uno de ellos se encargó de que ambos grupos hablaran y solucionaran los conflictos ocasionados por el desarrollo del proyecto.
  • Lección aprendida: En un grupo de un proyecto con tantas personas es común que algunas personas difieran en la toma de decisiones para la resolución de los problemas planteados respecto al desarrollo del proyecto, por ello la lección aprendida es que lo mejor es poner las opiniones en común y escoger la solución que consideremos mejor, sin que ello tenga que conllevar a problemas entre los miembros del equipo, ya que todos tenemos el mismo objetivo común.

6. Sprint 3

En el Sprint 3, nos centraremos en las últimas actividades antes de finalizar el proyecto, utilizando GitHub Projects para una planificación detallada en todos los repositorios. Implementaremos un dashboard con estadísticas generales del sistema, autenticación segura mediante llamadas a la API, y un sistema de sincronización local. Además, trabajaremos en el despliegue e integración continua en Google Cloud con GitHub Actions, una plataforma de pago y la validación de correos electrónicos a través de APIs externas. Abordaremos las peticiones de cambio de los usuarios piloto, incluyendo mejoras en la interfaz, funcionalidades de usuario y corrección de errores ortográficos.

• Contexto: El estado actual del proyecto se encuentra más avanzado de lo ideal, pero eso tiene como consecuencia que hay una sobrecarga de horas y se nota el agotamiento en algunos miembros. Esto se ha solucinado asignando un menor número de tareas a las personas que han dedicado un tiempo mayor al proyecto, lo que ha aumentado su productividad y ha ayudado a reducir ese estado de agotamiento respecto al proyecto.
  • Lección aprendida: Debido a la situación descrita, nos hemos dado cuenta que excedernos del número de horas planificado no tiene que ser algo positivo, aunque avancemos más de lo esperado. Esto es así porque el grupo va acumulando cansancio por la sobrecarga de trabajo que acaba en una disminución de la productividad y el deseo de una desconexión temporal del proyecto.

7. PPL

Para la preparación del lanzamiento del proyecto, llevaremos a cabo la campaña de publicidad preparada en el marketing del Sprint 3, realizaremos análisis técnico y financiero para comprender la situación de la empresa, elaboraremos un plan de lanzamiento para la fase de World Project Launch (WPL), y crearemos manuales de usuario detallados. Como parte de las acciones adicionales, nos centraremos en mejorar la experiencia de usuario, finalizar el feedback de los usuarios piloto y abordar aspectos como la responsividad, los estilos y la implementación de "Skeleton Loaders".

• Contexto: Se han creado tareas específicas para el marketing, por lo que miembros que desempeñaban un rol en específico se han visto con tener menos tareas de su rol, pero alguna tarea de marketing.
  • Lección aprendida: El hecho de cambiar la rutina de los miembros con estas nuevas tareas hacen que afronten con más ganas la realización de las mismas y estén más motivados.